home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
ccitt
/
1992
/
f
/
f500_1.asc
< prev
next >
Wrap
Text File
|
1994-01-31
|
57KB
|
1,276 lines
Recommendation F.500
INTERNATIONAL PUBLIC DIRECTORY SERVICES
Given the rapid multiplication and expansion of CCITT-defined
telecommunication services, there is a growing need for subscribers
to these telecommunication services to be able to communicate with
each other. In order to facilitate such intercommunication for the
subscribers of the various services, public directory services will
be required.
The CCITT,
considering
(a) that the CCITT-defined telecommunication services,
including Telegraphic, telematic and telephone services, have
directory requirements;
(b) that such requirements are being implemented as on-line
electronic directories (in addition to traditional hard-copy
versions);
(c) that national initiatives are being taken to develop
electronic integrated directories or service specific directories;
(d) that the system definition is being undertaken by the
CCITT in the field of electronic directories in the X.500-series of
Recommendations,
unanimously declares
that the specifications of this Recommendation should be
applied to the provision of public directory services.
CONTENTS
1 Introduction
2 Purpose and scope
3 Organizational provisions
4 Public directory services
4.1 Service requirements
4.2 Service features and optional user facilities
4.3 Further features and facilities
4.4 Service controls
5 Names as the key to directory searches
5.1 General
5.2 Entries
5.3 Distinguished names
5.4 Classification of requests
5.5 Naming of entries
5.6 Qualification of attribute types
6 Character repertoire and languages
6.1 Character repertoire
6.2 Language of requests to the directory and responses from
the directory.
7 Display of a response
8 Operational issues
8.1 Management
8.2 Authentication
8.3 Access control
8.4 Operational actions
8.5 Maintenance of the directory information
8.6 Error handling
8.7 Operator assistance
9 Quality of service aspects
9.1 Availability
9.2 Security of directory information
9.3 Successful directory requests
9.4 Access
9.5 Response time
10 References
Annex A - Abbrevations
Annex B - Service error messages
Annex C - Selected object classes
Annex D - Selected attribute types
Annex E - MHS selected object classes
Annex F - MHS selected attribute types
Annex G - User visibility of the search operation
Annex H - Glossary of terms
1 Introduction
International public directory services will enable
subscribers to determine rapidly and easily what services are
available and how to access and address their correspondents.
Public directories may also be used internally by the various
telecommunication services for the proper routing of calls or
messages. However, this application of directory systems is not
covered by this Recommendation.
Service specific directories may be implemented as part of a
global directory service. Consistent with the need to make
directory information as widely available as possible, it is
anticipated that Administrations will aim to provide global
electronic directory services.
In order to provide international public directory services,
Administrations should mutually cooperate in handling inquiries for
information across national boundaries.
Public directory services should solve the primary problem of
name to address association, e.g. obtaining a company's telex
number by querying the directory with the name of the company. The
reverse question, i.e., obtaining the name and other information
from the address, may also be applicable in certain services and
its provision is at the option of an Administration.
Public directory services should include directory information
concerning the provision of services, service descriptions,
operational instructions, tariff conditions, etc.
Public directory services should make provision for accessing
information without knowing the name of the object sought, e.g.,
designating categories of goods, business areas or services.
Advertising is included in the scope of public directory
services, but is left to national implementations.
Public directory services can be considered as supplementary
to the services for which they provide information or by which they
are accessed.
Private directory services which are compliant with the public
directory services defined in CCITT Recommendations may be
permitted to intercommunicate with public directory services under
national regulations.
2 Purpose and scope
This Recommendation provides for the general framework for the
provision of international public directory services. It defines
the requirements for and the service features associated with the
provision of public directory services. It specifies naming
aspects, describes operational issues to be taken into account in
providing the public directory services as well as quality of
service aspects.
3 Organizational provisions
Provision of a public directory service will be done in
accordance with the organizational model described in
Recommendation X.501. An Administration Directory Management Domain
(ADDMD) is responsible for the application of the basic service
features and the optional user facilities provided in that domain.
Directory management domains shall intercommunicate with each other
as far as the provision of the public directory services requires
it. The protocol to be used for interworking as well as the
directory's overall concept and behavior, is described in the X.500
series of Recommendations.
Private Directory Management Domains (PRDMDs) may exist and
intercommunicate with ADDMDs, following national regulations.
A Directory Management Domain (DMD) consists of one or more
Directory System Agents (DSAs) and zero or more Directory User
Agents (DUAs).
Each directory management domain may act as the naming
authority for that domain. Names need to be unambiguous.
The intercommunication between PRDMDs is outside of the scope
of this Recommendation.
4 Public directory services
4.1 Service requirements
The fundamental ability of a public directory service is to
provide a means by which subscribers or users of telecommunication
services may, in a user-friendly manner, and from information they
would normally possess, obtain information about a desired
recipient, such as addresses or communication capabilities.
This public directory service is provided in an on-line and
interactive manner. It should be made available for subscribers or
users at the discretion of the Administration offering the service.
Each Administration is responsible for the access methods
used. The characteristics of the access methods between terminals
and the public directory service are a national matter. However,
the directory service offered is independent of the access method,
the terminal used and the location of the user.
Public directories of Administrations should intercommunicate
(or refer to each other) to fulfill requests made by customers when
the directory serving the customer does not have available the
information requested.
4.1.1Basic service requirements
The following basic service requirements are fulfilled by the
public directory services:
- to provide subscribers with information, e.g., a telex
number, needed for establishing communication with other
subscribers or users of telecommunication services;
- to provide subscribers with information, e.g., service
instructions, needed to use the telecommunication services
and the directory itself;
- to assist subscribers in the formulation of queries to
narrow the scope of the operation;
- to allow for flexibility in the formulation of a request,
e.g., names should not artificially remove natural
ambiguities; names should admit natural abbreviations and
commonly used variations in spelling.
4.1.2Non-basic service requirements
The following non-basic service requirements are fulfilled by
the user facilities of the public directory services.
- to provide subscribers with other information, e.g.,
advertising;
- to provide subscribers with ôyellow pageö information,
e.g., categories of goods, business areas or services;
- to provide an interted directory for specific services,
e.g., for telex and teletex;
- to provide ôwildcardsö capability to ease, as far as
possible, the input of the requests to the directory;
- to provide means for the verification of credentials, under
conditions specified by the provider of the directory
service;
- to provide possibilities for the search of distribution
lists;
- to provide means for the phonetic matches.
4.2 Service features and optional user facilities
The service features and the optional user facilities of a
public directory service will be provided in accordance with the
X.500-series of Recommendations. The terms used in the context of
service features and optional user facilities discussed below are
explained in Annex H.
4.2.1Basic service features
Basic service features are inherent in directory services and
are always available for use in directory service. They are
provided by all service providers offering international public
directory services or by private directories intercommunicating
with public directory services.
The basic features are:
- read operation;
- search operation.
Other basic features are for further study.
4.2.2Optional user facilities
Optional user facilities may be selected by the user or
subscriber at the time the service is being used. Each optional
user facility visible to the user is classified as either essential
or additional. Essential (E) optional user facilities are to be
made available internationally by Administrations. Additional (A)
optional user facilities may be made available by Administrations
for national use and for international use on the basis of
bilateral agreement.
The major terms used in this Recommendation are contained in
Annex H.
The classification of optional user facilities is shown in
Table 1/F.500.
TABLE 1/F.500
Classification of optional user facilities
Classificati
on
Abandon E (see Note
1)
Add A
Additional service A
controls
Compare A
Distribution lists A
List A
Management of access A (see Note
control 2)
Modify A
Remove A
Security capabilities A
Time limit service E
control
Note 1 - This abandon operation is not guaranteed outside of the
local scope, i.e., the DSA or DMD to which the original request was
made.
Note 2 - The full functionality is presently not provided in the
present system specification of the X.500 series of Recommendations
(see X.501, º 3 and Annex F). This is for further study and
referred to as being presently a national matter. Access control
functions are for further study.
Other optional user facilities are for further study.
4.3 Further features and facilities
Some of the following items are not yet specified as elements
of service in the X.500 series of Recommendations and will be
studied further. Some others will need further study under service
aspects. The following list may provisionally be considered as
guidance for service providers to be taken into account for the
provision of public directory services under national
responsibility. The items may become basic features or optional
user facilities in the future or/and will be included with
descriptive text in future Recommendations.
- Provision of inverted directories for telex and teletex
services.
- Provision of additional information with or after the
result of a query.
- Provision of query cost information.
- Provision of information about services, service
instructions, tariffs, etc., in standardized formats taking
into account additional attributes.
- Provision of additional service controls.
- Provision of full functionality of access control
mechanisms.
- The ability of the user to indicate the desire not to
receive partial results when service control maximum
parameters are exceeded.
- Provision of the return of multiple responses in groups of
n (n = any number).
- Provision of administrative procedures for authentication.
- Provision of standardized error service messages.
- Provision of shadowing (controlled replication) of
directory information.
- Provision of geographical extension.
- Consequences of distributed directory services.
4.4 Service controls
Because of its generality and scope, the direcory service can
fulfill subscribers' requests that might require consumption of
resources beyond a level desired by the subscriber or by the
service provider. Service controls help to prevent such situations
by imposing limits on the resources that may be consumed in
fulfilling a request for service. Service controls not impacting
the provision of international directory services are a local
matter. The following service controls are provided by the system
application (see Recommendation X.511):
4.4.1Prefer chaining
This service control indicates a choice for chaining over
referral and multicasting. For the international intercommunication
of public directories, chaining is the preferred choice.
The setting of this service control is for the service
provider who may allow the user to invoke it.
4.4.2Chaining prohibited
The scope of a search will then be limited to the local
portion of the Directory Information Base (DIB) by prohibiting
chaining.
The setting of this service control is for the service
provider who may allow the user to invoke it.
4.4.3Local scope
The scope of the operation will be limited to the local
portion of the DIB. The determination of local is restricted to a
single DSA or DMD in accordance with an Administration's policy.
For the international intercommunication of public
directories, generally no limitation to local scope is assumed.
Public directories will aim to open their scope as much as
possible. The setting of this service control is for the service
provider who may allow the user to invoke it.
4.4.4Do not use copy
This service prevents a DMD from returning copied information.
The setting of this service control is for the service
provider who may allow the user to invoke it.
4.4.5Do not dereference alias
This service control allows reference to an alias entry itself
rather than to the aliased entry.
The setting of this service control is for the service
provider.
4.4.6Priority: low, medium, high
The setting of this service control is for the service
provider.
The usefulness of this service control is for further study.
4.4.7Time limit
The scope of this service control is to limit an operation in
terms of total elapsed time such that if the limit is exceeded,
then the operation will be terminated, and for search and list
operations partial results should be returned, with the indication
that results are incomplete due to the time limit. This service
control shall be honoured by any DMD involved.
The setting of this service control is for the service
provider who may allow the user to invoke it.
Note - This service control is an essential optional user
facility. All service controls other than the time limit are a
local matter and when implemented, need not be made available by
the service provider to the user.
4.4.8Size limit (applicable to search or list operations)
If the list size specified is exceeded any results equal in
number to the size limit should be returned, with the indication
that the results are incomplete due to the size limit.
The setting is for the service provider who may allow the user
to invoke it.
4.4.9Scope of referrals
Indicates the scope to which a referral (or advice), if
generated, is to be restricted to, i.e., limits the range of
alternate access points at which the requestor (DUA or DSA) may
alternately use to satisfy the request. The limitation can be
restricted to a country or DMD.
The setting of this service control is for the service
provider who may allow the user to invoke it.
Note - Combination of some service controls may affect the
quality of the results, e.g., combination of priority, time limit
and size limit may conflict, or chaining cannot be both preferred
and prohibited simultaneously. If no service controls are supplied
with an operation, the following is assumed: referrals and/or
chained operations may be used; no limit on the scope of the
operation; locally held copies of information are permitted; no
preference of priority for operation processing; there is no time
or size constraint; referrals, if generated, are not restricted to
a DMD or country; and aliases are dereferenced.
5 Names as the key to directory searches
5.1 General
A name within the directory service is a label which is
constructed to identify a particular object, that is, which singles
out an object from the set of all objects. A name should not be
ambiguous, that is, should not denote more than one object.
However, there may be more than one name for an object. Thus, it is
possible to call an object by the name International Widget Makers
or IWM. In either case, one and only one object is identified.
A more abstract definition of ônameö can be found in Annex H.
5.2 Entries
The directory service will provide information about entries.
The complete set of such information is called the Directory
Information Base (DIB). The information about entries is composed
of attributes; attributes, in turn, are composed of an attribute
type (one type of attribute could be a telex number) and one or
more attribute values. (The actual telex number would be a value.)
The entries are arranged in a tree, called the Directory
Information Tree (DIT). This is graphically illustrated in Figure
1/F.500. However, this does not preclude other directory
information structures.
Thus, an entry may be viewed as an entity which is named
through one or a series of attributes. A company may be
sufficiently named simply through the use of its actual legal name
e.g., the PADRAIC STEEL CO. A plumber in Secausus, N.J. can be
named through the use of his common name, his postal address and
his business category ôplumberö. A human person may be named
through the use of his or her common name and telephone number.
5.3 Distinguished names
It should be noted that within the directory system
recommendations, the term ôdistinguished nameö is used. This is the
combination of the minimum attribute value assertions (AVAs) needed
to denote an entry uniquely. This minimum will be established in
accordance with the requirements of the naming authority and/or the
directory management domain, and the preference of the owner of tne
entry named. Use of the distinguished name may be of assistance in
performing the most effective search of the DIB. However, it should
be recognized that in some instances, distinguished names may not
be user friendly and may contain information, which, in fact, is
the object of the directory search, i.e., a person's postal
address.
Figure 1/F.500
5.4 Classification of requests
To satisfy the most common needs of directory users which are
presently met by so-called ôwhite pagesö or ôyellow pagesö
(classified directories) or organization directories, three
classifications of requests to the directory service are provided.
5.4.1Common name requests (type 1)
Information returned under this type of request includes
information about one or more of the following entries. (Selected
object classes can be found in Recommendation X.521; they are
listed in Annex C.)
a)A person
Example: Bernadette L. Casey
b)A residential person
Example: Cornelius Fecit
2 Humbug Road
Fun City, New York 11666
USA
c)An application entity
Example: Some logical name, usually a sequence of alpha
and/or numeric characters identifying an application
process; consequently not necessarily user friendly.
d)A communication device
Example: the XYZ 9.6 modem (however, this information is
normally associated with an organization and is thus
generally of greatest utility to organizations).
e)An alias
Example: Neil Fecit [an alias for the residential
person in b)]
f)An organizational role
Example: Director of regulatory affairs
g)A group of names
Example: Members of special rapporteur's group Question
14/1.
5.4.2Business category requests (type 2)
Information returned under this type of request includes
information about one or more of the following entries. (Selected
object classes can be found in Recommendation X.521; they are
listed in Annex C.)
a)A person
Example: John Smith
b)A residential person
Example: John Smith, with the rest of the postal
address
c)An organization
Example: The Padraic Steel Company
d)An organizational unit
Example: Regulatory Affairs Department
e)A group of names
Example: The plumbers in Secausus
5.4.3Organization requests (type 3)
Information returned under this type of request includes
information about one or more of the following entries. (Selected
object classes can be found in Recommendation X.521; they are
listed in Annex C.)
a)An organization
Example: The Padraic Steel Company
b)An organizational unit
Example: Regulatory Affairs Dept.
c)An organizational person
Example: John Jones, Padraic Steel Company
d)An organization role
Example: Chief Operating Office
e)A group of names
Example: The President's Staff
f)An application entity
Example: as above in º 5.4.1 c)
g)A device
Example: An XYZ 9.6 modem
h)An organizational unit alias
Example: the ôbean countersö which is an alias for the
ôController's Dept.ö
i)An organizational name alias
Example: GMC for ôGood Modern Cooks Inc.ö
5.4.4Use of attributes
Attribute types that are recommended to be included, whenever
they exist (subject to the permission of the owner) in each entry
of each group, either for query or retrieval, are listed in Table
2/F.500 (see also Annex D).
TABLE 2/F.500
Use of attributes for each type of request
Attribute type Abbrevi for for for
ation Type 1 Type 2 Type 3
Business category BCTG - M R
Common name COM M Q Q
Country name CTN M M M
Description (free DES R R R
text)
Destination DI - - -
indicator (public
telegram)
Facsimile FAX - Q Q
telephone number
ISDN address ISDN - Q Q
Knowledge KI - - -
information
Locality name LOC M Q Q
Member MEM R R R
Object class CLASS Q Q Q
O/R address (MHS) O/R R R Q
(see Note 1)
Organization name ORG - - M
Organizational OUN - - Q
unit name
Owner OWN - - -
Physical delivery PDO Q Q Q
office name
Post office box POB Q Q Q
Postal address PADD Q Q Q
Postal code (see PCOD Q Q Q
Note 2)
Preferred DLM R R R
delivery method
Presentation PRADD R - R
address
Registred address RADD - R R
(public telegram)
Role occupant RO R - R
Search guide SG R R R
See also SEE R R R
Serial number SN - - -
State or province STN M (see Q Q
name Note 3)
Street address SADD Q Q Q
Supported SAC Q Q Q
application
context
Surname SUR Q Q Q
Telephone number TEL Q Q Q
Teletex terminal TTX R Q Q
identifier
Telex answerback A/B R R R
(see Note 4)
Telex number TLX R Q Q
Title TIT - - Q
User certificate UC R R R
User password UP R R R
Videotex user VTX Q Q Q
number (see Note
4)
X.121 address X.121 - Q Q
Note 1 - This attribute type is defined in the X.400 series of
Recommendations.
Note 2 - The postal address will normally contain the postal code.
Requirements may exist to justify the postal code as being a
separate attribute type. Specific conditions are applied to a
postal address for Physical Delivery (see Recommendation F.401).
Note 3 - Depending on the value of the attribute ôCTNö.
Note 4 - This attribute type has not yet been defined in
Recommendation X.520.
M Mandatory to reach an object of this type.
Q May be used to reach an object of this type (within a
distinguished name or as a search filter), but may also be part o
the directory response. Additional attribute types may be used for
selection criteria within national implementations.
R Normally part of the directory response with regard to the
request of the user.
- This attribute type may either be part of a local sub-object
class or used nationally.
Some terms used in Table 2/F.500 are explained in Annex H.
Definitions of other terms can be found in the X.500 series of
Recommendations.
5.5 Naming of entries
To reach an entry, a user has to provide some information, a
part of which is essential to the performance of the request (e.g.,
the provision of attributes CTN, ORG, CLASS, for an organizational
object), as described in º 5.2.
Depending on the knowledge the user has about the naming
structure of the part of the directory information tree (DIT) to
which the entry of the intended object belongs, the request
information provided by this user to reach the intended entry is
either the distinguished name of the entry (in which case the
response is unique), or the value of some relevant search
attributes (already known by the user) arranged in a logical
pattern to act as a filter to reduce as far as possible the number
of the directory responses.
Since distinguished names have to be unambiguous, it is not
expected that they will always be user-friendly. For instance, a
name of a residential person may include the telephone number and
thus be rather difficult to predict, especially if the telephone
number is the information requested from the directory. It is
recognized that the distinguished name (DN) of an object may not be
commonly known, in which case the DN may be acquired by using a
list operation and in some instances a search operation.
To perform efficiently the search or list operation, it is
recommended that one narrows as far as possible the scope of the
search, either by giving a base object (from which the search
starts in the DIT) near enough to the intended entry (in terms of
DIT levels), or by obtaining and using the appropriate filtering.
It should be possible to obtain from the directory which of
the attributes (qualified with ôQö in Table 2/F.500) may be used as
part of the search filter for a given object class starting from a
given base object. However, it is recognized that the use of this
feature across domain boundaries is subject to national
restrictions and bilateral agreements.
It is expected in most cases that a directory management
domain will be able to provide from previous experience the useful
search criteria of subordinate levels, whether or not they
efficiently manage those levels, without exploring the DIT further
for each request. Knowledge of the search criteria may also be
acquired by DUAs from the directory by automatic means, e.g., by
reading the ôsearch guide attributeö if available.
It is up to the Directory Management Domain (DMD) managing a
given entry to select from the attribute types specified in º 5.4
for use as search criteria.
The use of wildcards to replace the value or part of the value
of unknown recommended search criteria should be made possible.
Phonetic or orthographic extensions, when requested, may be
locally applied to the provided values for query operations.
However, their actual provision depends on the capabilities of the
directory system. The fall-back mode is phonetic or orthographic
extensions not supported.
5.6 Qualifications of attribute types
Some criteria of the selected attribute types require
qualification.
ôMandatoryö in Table 3/F.500 indicates that, if that attribute
type exists in an entry of the directory, it shall be part of any
response provided, when asked for by the user, and that no
combination of access controls may be kept on attributes which
would preclude provision of a meaningful directory service, subject
to the owner's approval.
The ôrequired lengthö of an attribute type in Table 3/F.500
designates the minimum number of character positions to be made
available for the attribute type to be displayed on the terminal of
a user, and can therefore assist Administrations in defining their
attribute values with the assurance that the attribute value will
not be truncated. (The X.500-series Recommendations have system
qualifications for the maximum length of attribute types.)
The system specification does not provide multiple values for
country name and preferred delivery method. All others may be
recurring. For example, an organization may be ôPadraic Steelö and
ôPadraic Steel Companyö. Only one value needs to be displayed to
the user.
Table 3/F.500 contains a list of the user-visible selected
attribute types to be used in the directory service. The figures
shown may require revision in the light of experience.
TABLE 3/F.500
Qualifications of attribute types
Attribute type Mandator Required
y length
Business category Yes 128
Common name Yes 64
Country name (see Note 1) Yes 30
Description Yes 1024
Destination indicator (public Yes 4
telegram)
Facsimile telephone number No 150
ISDN addresse No 16
Knowledge-information No -
Locality name Yes 64
Member No -
Object class No -
O/R address MHS (see Note 2) Yes -
Organization name Yes 64
Organizational unit name Yes 64
Owner No -
Physical delivery office name No 64
Post office box No 40
Postal address No 180
Postal code (see Note 2) No 20
Preferred delivery method (see Yes 15
Note 3)
Presentation address No -
Registered address (public Yes 60
telegram)
Role occupant No -
Search/Guide Yes -
See also Yes -
Serial number No 64
State or province Yes 64
Street address No 64
Supported application context No -
Surname No 64
Telephone number No 16
Teletex terminal identifier No 24
Telex answerback (see Note 2) No 21
Telex number (see Note 3) No 36
Title No 64
User password No -
User certificate No -
Videotex user number (see Note 2) No 17
X.121 address No 15
Note 1 - The system specification provides only a 2-character
length, to correspond to the ISO 3166 value.
Note 2 - The postal address will normally contain the postal code.
Requirements may exist to justify the postal code as being a
separate attribute type. Specific conditions are applied to a
postal address for Physical Delivery (see Recommendation F.401).
Note 3 - The system specification provides a shorter field.
Note 4 - For some attribute types, values are stored in
encoded/compressed format and will need to be displayed in a non-
encoded format or human readable format.
Note 5 - See also Recommendation X.520, Annex C.
6 Character repertoire and languages
6.1 Character repertoire
Directory information will be entered and stored locally using
a character repertoire suitable to the country where the directory
is located. More than one character repertoire may be needed to
cover different languages or to provide for access from different
types of communication terminals.
However, in order to provide international public service, the
character repertoire to be used internationally should be limited
to CCITT standardized sets, i.e., the IA5 and T.61 character
repertoires.
For the intercommunication between public directory services,
the repertoires may be agreed to bilaterally.
However, where no such agreement exists, the character
repertoire to be used shall consist only of those characters
defined as ôprintable stringö in Recommendation X.208. Furthermore,
those Administrations which use character reportoires other than
this repertoire shall provide suitable conversion of the
information into this character repertoire for directory requests
from Administrations with which no bilateral agreement has been
reached.
Subscribers have to be instructed on the use of the
appropriate character repertoires.
6.2 Language of requests to the directory and responses from the
directory
Subject to the conditions in º 6.1, the results of requests to
the directory should normally be provided in the language or
languages of the DMD providing the information. However, the
information is presented to the requestor is a national matter.
7 Display of a response
Attribute types and values will be displayed to the user, when
required, by converting the values in accordance with
Recommendation X.408.
Though it is logical enough that the right response always be
sought, in some cases where no such answer can be provided, and on
explicit request of the requestor, the directory may also provide
phonetic and orthographic extensions corresponding to the intended
object.
For displaying directory responses, the following order is
recommended:
a)the right answer(s);
b)the answer(s) approaching the right answer(s) using
conjunctions, particles, articles, as well as extended or
concatenated abbreviations;
c)the phonetic and orthographic extensions (e.g. plural
instead of singular denominations). It should be noted that
such responses may be erroneous.
Partial responses, including referrals, should be displayed to
the requestor and properly identified as such. The cause for
partial responses should also be displayed.
8 Operational issues
8.1 Management
It is the responsibility of the Directory Management Domains
(DMDs) to exercise the management of information within their
Domains. Inter-Domain Management is for further study.
8.2 Authentication
Authentication in this context means that the identity of the
subscriber or user is established. In some cases, the directory
service has to ensure that directory information is released only
to authorized requestor(s), and in some cases it has to ensure that
data is modified only by an authorized originator (e.g., by
employing techniques related to data origin authentication).
Checking and keeping of credentials, when performed, are at
the discretion of the DMD, taking into account the requirements of
privacy of the owner of the information. The precise reason for
credential failure will be masked from the user. The user will be
advised that denial of the request was because an inappropriate
authentication level was encountered.
See also Recommendation X.509.
Further study is required.
8.3 Access control
Access controls are a national matter. When access control
prohibits the return of the information requested, an appropriate
code error code will be returned.
Note - The international application of access control is for
further study.
8.4 Operational actions
Actions performed within a directory can be categorized as:
1)primary (subscriber/directory) action - always in direct
support of a subscriber;
2)secondary action in support of a subscriber request, either
serving the subscriber's DUA or an intermediary DSA.
These actions are qualitatively different, and differ also in
what they imply concerning the obligations of an ADDMD.
Examples of such interactions can be found in Recommendation
X.518.
8.4.1Primary (subscriber/directory) action
The public directory service should provide three user-visible
activities of support, as follows:
a)Request formation
In this activity, the subscriber composes a request to the
directory. The way in which these functions are performed
is a national matter.
b)Presentation of results
In this activity, the directory service presents to the
subscriber the results of a previously entered request. The
format, presentation medium and other aspects of result
presentation are a national matter.
c)Subscriber assistance
In this activity, the directory service assists the
subscriber by providing instructions on the use of the
directory. The means through which the subscriber asks for
such instruction, and the manner in which an instruction is
delivered, are a national matter.
8.4.2Secondary action for subscriber support
In order to provide the public directory service, DMDs shall
cooperate. Such cooperation includes adherence to defined patterns
of interaction, and also includes provision of requested directory
information to one another, subject only to internationally agreed
access controls (or bilateral arrangements). This technical
cooperation among DMDs implies an equivalent level of cooperation
in service terms, especially with regard to information sharing,
among the DMDs. Examples of such interaction can be found in
Recommendation X.518.
8.5 Maintenance of the directory information
The service provider has to ensure integrity of the
information contained in the directory. Shadowing (controlled
replication) of information in other DMDs is permitted by bilateral
agreement. The international application is for further study.
Creation and modification of directory information by the
subscribers may be permitted by the DMDs concerned.
8.6 Error handling
Error conditions will be returned as a value of an error code
for all standardized operations. The meaning will be displayed
according to national implementations as service error messages to
the user.
See Annex B/F.500 for guidance.
8.7 Operator assistance
For further study.
9 Quality of service aspects
9.1 Availability
In principle, a public directory service should be available
to subscribers 24 hours a day, seven days a week.
9.2 Security of directory information
Information in public directories should be given the broadest
dissemination. However, subscribers or users about whom information
is available in a directory should be able to require the entity
charged with the management of the directory to limit access to
such information to ensure their own privacy.
9.3 Successful directory requests
Normally, a successful directory request will result in a
report of all the requested information, unless it is denied
because of authorization restrictions.
Requests to the directory which do not provide sufficient
information to execute a reasonable search will normally not lead
to a successful result.
9.4 Access
Providers of a public directory service should ensure that an
adequate number of access ports are available to accommodate
subscribers' requests for information. In principle, this means
that a requestor will receive a prompt within 15 seconds as a goal.
9.5 Response time
Recognizing that responses to requests will be controlled in
part by the level of ambiguity tolerated in requests and the number
of DMDs which shall be traversed to retrieve the information
requested, a subscriber normally should expect an initial
acknowledgement regarding his request within 5 seconds. The scope
and priority of the request may have an impact on the response
time. The requestor may terminate his request at any time.
A final response (successful or unsuccessful) will depend on
the capabilities of the directories consulted. A response
indicating that no information or incomplete information is
available (possibly with hints for further searches) should be
given within one minute.
Note - The figures for quality of service are provisional and
may be revised in the future.
10 References
10.1 Recommendations of the X.500 series - Data communication
networks: directory
X.500 The directory - Overview of concepts, models and
services
X.501 The directory - Models
X.509 The directory - Authentication framework
X.511 The directory - Abstract service definition
X.518 The directory - Procedures for distributed operation
X.519 The directory - Protocol specification
X.520 The directory - Selected attribute types
X.521 The directory - Selected object classes
10.2 Recommendations of the X.200 series - Data communication
networks: open systems interconnection (OSI)
10.3 Recommendations of the F.400 series - Message handling and
directory services operations and definition of service
10.4 Recommendations of the X.400 series - Data communication
networks: message handling systems
